home *** CD-ROM | disk | FTP | other *** search
/ Univers Mac Interactif 43 / Univers Mac Interactif - Issue 43.iso / univers mac N°43 / Reseaux / internet / internet utilitaires / NewsWatcher folder / posting-delays-note.txt < prev    next >
Text File  |  1994-12-09  |  6KB  |  112 lines
  1. This note explains the posting delay some NewsWatcher users experience
  2. with some news servers. It is redistributed with the permission of the
  3. author, Jerry Aguirre.
  4.  
  5. This problem is also discussed in FAQ #2 in Appendix F of the NewsWatcher
  6. user document, which is reproduced below:
  7.  
  8. FAQ #2    Posting takes forever. The status window appears, and the stupid
  9. beachball cursor just spins and spins and spins. If I wait a bit and then cancel,
  10. my posting seems to go through OK. What's wrong with this brain-dead program,
  11. anyway?
  12.  
  13. While NewsWatcher has not yet achieved artificial sentience, it is not completely
  14. brain-dead either. This is a server problem, not a NewsWatcher problem. Your
  15. server is very, very slow. This is a fairly common problem at some sites which
  16. run old versions of servers or misconfigured servers. NewsWatcher takes only a
  17. few seconds to send your posting to the server, then it waits for the server to
  18. send back the final response that says "OK—posting complete" or "Error—something
  19. went wrong". NewsWatcher has to wait for this final response so that it can tell
  20. you if something went wrong. Things can and do go wrong with postings, like disk
  21. full errors on the server or any of a number of other problems. NewsWatcher has
  22. to let you know if there's a problem, because otherwise your posting would
  23. disappear into a big black hole without your ever realizing it, and that would
  24. not be nice. Only your server administrator can fix this problem. For more
  25. detailed information, get the following note and show it to your news server
  26. administrator:
  27.  
  28. ftp://ftp.acns.nwu.edu/pub/newswatcher/posting-delays-note.txt
  29.  
  30. ------------------------------------------------------------------
  31.  
  32. Date: Thu, 20 Oct 94 21:58:03 PDT
  33. From: jerry@strobe.ATC.Olivetti.Com (Jerry Aguirre)
  34. To: j-norstad@nwu.edu
  35. Subject: Re: Getting Rid of Posting Delays
  36. Newsgroups: news.software.nntp
  37. Organization: Olivetti ATC; Cupertino, CA; USA
  38. Cc: 
  39.  
  40. In article <j-norstad-1910941126230001@norstad.acns.nwu.edu> you write:
  41. >The problem appears to happen only in the ref. imp. server (nntp), which
  42. >sometimes accepts the POST command and the text of the posting, but then
  43. >delays for a very long time before sending back the final "OK" or "error"
  44. >response. I get lots of mail from my users complaining about this. What
  45. >I'd like to do is put a FAQ in my user doc with explicit instructions for
  46. >how to fix the ref. imp. server to not do this, so my users can pass the
  47. >instructions on to their news administrators.
  48.  
  49. In short, this problem results from running old versions or
  50. mis-configuration.  Modern configurations just spool postings to
  51. a file for later processing.  The user gets immedate return but
  52. may not see the posting appear til later.
  53.  
  54. The "refference NNTP" is not a full news package.  It was orriginally
  55. designed as an adjunct to the B news system.  It is still used with
  56. the C news system.  It adds NNTP capability to an existing news system.
  57. (INN has its own NNTP code built in.)
  58.  
  59. When NNTP gets an article from xfer or post it envokes rnews or inews
  60. to process it.  In B news this was the only way to process articles.
  61.  
  62. But hardly anyone runs B news anymore.  C news was written to improve
  63. performance and generally clean up the code.  To get improved performance
  64. C news was designed to process articles in batches.  Most UUCP sites
  65. got their news in compress UUCP batches.  The C news article processor
  66. would go thu the setup overhead once and then process multiple batches.
  67. This was much faster than B new which would run an rnews process for
  68. every incomming article.  All the locking and parsing of configuration
  69. files for each article would really slow B news down.
  70.  
  71. But C news has a problem with posting.  The posting program needs to
  72. lock access to the news.  If lots of batches are running then they
  73. could take a while to finish before allowing inews to run.  Also
  74. C news is not happy with the individual articles that NNTP hands
  75. to it.  It has to go thu a lot of overhead to just process one article.
  76.  
  77. So, modern versions of the refference NNTP implementation have a
  78. configuraton option to not run rnews or inews for every article.
  79. Instead incomming articles are put in batch files on disk.  After
  80. a limit is reached it will start a new batch file.  Incomming posts
  81. are just spooled to a temporary file.  NNTP returns quickly.
  82. There were also problems with getting the correct permissions and
  83. such from user generated posts which this corrects also.
  84.  
  85. Later, when C news runs its crontab driven job, the incomming posts
  86. and new articles are processed.  Of course there can be considerable
  87. delay between the user posting and the article actually appearing
  88. in the spool.  Some people run the C news processor (I think it is
  89. called "relaynews") every minute.  Others have a loop that runs it
  90. continuously.
  91.  
  92. So, the answer is to get a modern version of C news, a modern
  93. version of NNTP, and to configure them correctly.  Actually I think
  94. that the recent release of C news is supposed to have built in NNTP
  95. code but I have not looked at it personally.
  96.  
  97. INN was designed with different assumptions.  It uses a continuous
  98. daemon and network connections to communicate with it.  It handles
  99. incomming feeds directly with no intermidate copying of the articles.
  100. Posting with INN can be a little tricky in some configurations but
  101. when properly configured the posting is handed off to the INN daemon
  102. which handles it along with other incomming news.
  103.  
  104. The down side of INN is that it requres features that C news does
  105. not.  You must have sockets and having "unix domain sockets" is even
  106. better.  It really wants to have a working MMAP system call.  Also
  107. it was designed to trade memory usage against disk and CPU.  So it
  108. chews up 5-9 Megabytes just for the INN daemon.  If you don't have
  109. at least 16 Megabyes then just forget it.
  110.  
  111.                                 Jerry Aguirre
  112.